When a program is developed, structured programming is strongly recommended. Specifically, for example, a module is required to be made by combining processing sections each including relatively few sentences. Moreover, the module is required not to use unconditional branch statements (GOTO statements) but to be provided with nested structure (i.e. hierarchical structure) formed with conditional statements and repeat statements. Moreover, a process common to a plurality of the modules is required to be modularized. Accordingly, for example, when a system includes programs whose total sum of sentences is over one million, the system often includes several thousand modules each having several ten processing sections.
In such a large-scale system as described above, persons involved in development thereof, or persons who sufficiently know the relation among the modules and the structure of each of the modules, often maintain the system for a while after the development. However, such a system is often used over several ten years while being repeatedly maintained. As time passing by, the persons involved in the development are gone so that persons who do not know the structures of the modules are required to maintain the system. In such a case, because the structured programming is used, they are forced to figure out the functions each of which is described separately in a large amount of the modules so that the maintenance becomes extremely difficult. In other words, structural analysis of the module becomes difficult.
In order to understand the function of the whole module or the function of each processing section, it is necessary to figure out the hierarchical structure formed with the conditional statements (hereafter, simply referred to as “hierarchical structure”). However, the module in the large-scale system often has deep hierarchical structure (for example, hierarchical structure having ten or more hierarchies). In such a case, it is not easy to figure out its hierarchical structure. Accordingly, for example, a part similar to a maintained part (for example, a part having similar function) may be missed so that a necessary maintenance is not done.
As can be seen from the above explanation, a system can be more easily and more properly maintained if its hierarchical structure can be easily figured out. Moreover, by finding out parts having hierarchical structures same as each other, maintenance for the similar part can be prevented from being missed. For example, each of Patent Document 1 and Patent Document 2 discloses a technique which supports for figuring out the hierarchical structure.
Patent Document 1 discloses a program development support device which changes, when displaying a program (module), display color of a statement according to its depth in nested structure (i.e. hierarchical structure) formed with IF-statements. Accordingly, a program developer can visually figure out the hierarchical structure. According to a structure program compiling apparatus disclosed in Patent Document 2, when a program (module) is displayed, a statement including keyword that indicates hierarchy (for example, if or case) is displayed while other statement can be undisplayed or can be simply displayed. Accordingly, a program developer can relatively easily figure out the hierarchical structure.